Abp Suite - Create navigation/reference to identity service to return user name #10703

7 Answer(s)

• 

  0

  AI-Bot created 3 months ago

  Support Team ABP Agent

  • In a microservice solution you generally should not create an EF Core navigation property / foreign key to IdentityUser inside another microservice’s database, because IdentityUser lives in the Identity microservice (its own bounded context + its own database). That’s why ABP Studio/Suite doesn’t offer “Identity” as a selectable module entity for a navigation property in your WorkItem entity designer.

  • The recommended approach is:

    1. Keep AssignedUserId : Guid in WorkItem (as you already do).
    2. When listing WorkItems, enrich the DTO with the user’s display text by calling the Identity microservice (remote call) and mapping AssignedUserId -> UserName (or Name + Surname, etc).
    3. Optionally use a lookup endpoint from Identity to pick users in the UI.

  Concrete implementation (typical pattern)

  1. Add a display field to your list DTO (in your WorkItem application contracts), e.g.:

  public class WorkItemDto : EntityDto<Guid>
  {
      public Guid? AssignedUserId { get; set; }
      public string? AssignedUserName { get; set; } // <- add this
  }
  

  2. In your WorkItem AppService list method:

  • Query WorkItems from your own DB.
  • Collect distinct AssignedUserIds.
  • Call Identity service to get corresponding users.
  • Populate AssignedUserName.

  (How you call Identity depends on your solution’s existing microservice client setup, but conceptually you do a remote call to Identity’s user endpoints and join in-memory.)

  About “Do I have to add a package to my WorkItem service before I can reference AbpUsers?”

  • You should not add an EF entity reference to Volo.Abp.Identity.IdentityUser in another microservice’s domain model to create an EF relationship.
  • If you need user info, use remote service calls / client proxies to Identity instead of a direct EF navigation property.

  If you want ABP Studio/Suite “reference entity” support

  ABP Studio’s low-code “Reference Entities” list includes Identity User as a reference entity (for lookup/display purposes), not as a local EF navigation target in another microservice DB:

  • Volo.Abp.Identity.IdentityUser (typical display property: UserName)

  Validated source:

  • https://abp.io/docs/10.4/low-code/reference-entities

  Background: Identity is a separate microservice

  Validated source:

  • https://abp.io/docs/10.2/solution-templates/microservice/microservices

  Extra (non-microservice / monolith note)

  There is an article showing adding a user navigation property via Suite in a monolith-style setup (where user entity is in the same solution/bounded context). This is generally not the right model for microservices:

  • https://abp.io/community/articles/furp75ex

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  mhoffmeister created 3 months ago

  I have seen that I could add the package "Volo.abp.Identity.Pro.HttpApi.Client" to my WorkItem service so that I can request a user in my own "GetListWithUsernameAsync" in my WorkItemsAppService.Extended.cs and then map it to my customized DTO. Would that be correct or should I do it in an other way?

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  AI-Bot created 3 months ago

  Support Team ABP Agent

  • Yes, calling Identity from your WorkItem microservice and mapping AssignedUserId -> UserName in your custom list DTO is the correct approach for a microservice solution.
  • Adding an HttpApi.Client package (and using the generated client proxy) is exactly how ABP expects you to do synchronous inter-service communication.

  That said, in microservices you should prefer calling Identity’s Integration Service (if available in your version/package set) rather than the full “UI/admin” Identity app service endpoints, because integration services are designed specifically for service-to-service scenarios.

  What to do

  1. Keep AssignedUserId as Guid in WorkItem (no EF navigation to IdentityUser).

  2. In WorkItemsAppService.Extended.cs, implement GetListWithUsernameAsync like:

     • get WorkItems from your DB
     • extract distinct AssignedUserIds
     • call Identity remotely (client proxy) to fetch users
     • fill AssignedUserName on your DTOs

  3. Ensure your microservice can forward the current user’s access token to the Identity service when doing remote calls. In ABP microservices this is handled by the Volo.Abp.Http.Client.IdentityModel integration (commonly used by microservice hosts) so the outgoing request contains the Authorization header.

  Notes about the package name you mentioned

  • Using an Identity .HttpApi.Client package is the right idea.
  • Whether you should use Volo.Abp.Identity.Pro.HttpApi.Client specifically depends on what your solution uses (Pro vs non-Pro) and which endpoints you need. The key is: use the Identity service’s HttpApi.Client (client proxy) for remote calls, not EF references.

  Sources (validated)

  • Remote calls with token forwarding in ABP microservices (Microservice Demo):
    https://abp.io/docs/latest/samples/microservice-demo
  • Interservice communication guide:
    https://abp.io/docs/latest/guides/interservice-communication
  • Integration Services (recommended pattern for service-to-service):
    https://abp.io/docs/latest/framework/api-development/integration-services

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  mhoffmeister created 3 months ago

  Just to make sure I understand it correctly. I could use "Volo.Abp.Identity.HttpApi.Client" instead of "Volo.Abp.Identity.Pro.HttpApi.Client" and then in my WorkItem service use the "IIdentityUserIntegrationService" to request the users to get the names, correct?

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 3 months ago

  Support Team Fullstack Developer

  Hi,

  Your direction is correct — call IIdentityUserIntegrationService from your WorkItem service and fill the username on the DTO. Since you're on a Business license and your IdentityService uses the Pro packages, go with Volo.Abp.Identity.Pro.HttpApi.Client (not the open-source one) so the contracts stay consistent across services.

  About why Suite doesn't list IdentityUser in that dropdown: in the microservice template, Identity runs as its own service with its own database, and your WorkItem service's Domain project does not (and should not) reference Volo.Abp.Identity.Pro.Domain. Suite hides it on purpose — cross-database EF navigation isn't possible here. Keep AssignedUserId as a plain Guid / Guid? and resolve the username at the application layer.

  The username data lives in the IdentityService database. ABP already exposes a built-in integration endpoint for this (/integration-api/identity/users/search/by-ids) — you don't need to write anything on the Identity side, just consume it from your WorkItem service.

  Three steps:

  1. Add the package to your WorkItem service .csproj:

  <PackageReference Include="Volo.Abp.Identity.Pro.HttpApi.Client" Version="$(YourAbpVersion)" />
  

  2. Add the module dependency in your WorkItem service module class. This is what registers the IIdentityUserIntegrationService client proxy in DI — without it the interface can't be resolved:

  using Volo.Abp.Identity;
  
  [DependsOn(
      // ...your existing dependencies
      typeof(AbpIdentityHttpApiClientModule)
  )]
  public class WorkItemServiceModule : AbpModule
  {
  }
  

  3. Inject the integration service in your WorkItemsAppService and enrich the DTOs after the list query. Use SearchByIdsAsync so it's one remote call per page, not N+1:

  private readonly IIdentityUserIntegrationService _identityUserIntegrationService;
  
  public WorkItemsAppService(
      /* ...existing deps */,
      IIdentityUserIntegrationService identityUserIntegrationService)
  {
      _identityUserIntegrationService = identityUserIntegrationService;
  }
  
  private async Task FillAssignedUserNamesAsync(IReadOnlyList<WorkItemDto> items)
  {
      var userIds = items
          .Where(x => x.AssignedUserId.HasValue)
          .Select(x => x.AssignedUserId!.Value)
          .Distinct()
          .ToArray();
  
      if (userIds.Length == 0)
      {
          return;
      }
  
      var users = await _identityUserIntegrationService.SearchByIdsAsync(userIds);
      var userMap = users.Items.ToDictionary(u => u.Id, u => u.UserName);
  
      foreach (var item in items)
      {
          if (item.AssignedUserId.HasValue &&
              userMap.TryGetValue(item.AssignedUserId.Value, out var userName))
          {
              item.AssignedUserName = userName;
          }
      }
  }
  

  Then call FillAssignedUserNamesAsync(result.Items) at the end of your list method (right before returning), and add an AssignedUserName property to WorkItemDto.

  A few notes:

  • The Suite-scaffolded appsettings.json already has RemoteServices:AbpIdentity:BaseUrl pointing to your IdentityService, so no extra configuration is needed.
  • Token forwarding to the Identity service is set up by the microservice template out of the box.
  • UserData also carries Name, Surname, Email, IsActive etc., so you can map other fields the same way if you need them later.

  If anything doesn't work or you run into any other issues, feel free to let me know.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  mhoffmeister created 3 months ago

  Thanks for the info. That really helped. :) I had to add the RemoteService to my appsettings.json though.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 3 months ago

  Support Team Fullstack Developer

  Great 👍

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel