Activities of "gterdem"

You may want to check these framework modules:

• Volo.Abp.Http.Client.IdentityModel
• Volo.Abp.Http.Client.IdentityModel.Web

Check the identityserver logs. https://idmstg-authserver.conlog.com/.well-known/openid-configuration should be reachable.

When does this error occur exactly? On which operation you are doing, you get this error? How can we reproduce it?

I am using the LocalDistributedEventBus which is default.

The user is created at IdentityServer and you are trying to handle it in an Http.Api.Host application. LocalDistributedEventBus works in-process. You need to use a distributed event bus provider like RabbitMq or Kafka.

Sorry, this issue seems IdentityServer specific and out of my expertise. Please also try asking to IdentityServer github issues or stackoverflow.

Can you also check the rabbitmq-management page when an event is published to guarantee the event is published?

It is not a good practice to inherit from IdentityUser. I would suggest using Object Extensions.

Or create a different entity isolating your user-related business:

public class AppUser: Entity<Guid>
{
    public Guid IdentityUserId {get; set;}
    public IdentityUser User {get; set;
}        

You can event use the same IdentityUserId for AppUser if you care.

Did you follow this configuration document?

It seems admin-service can not be resolved. Can you make sure this DNS is correct and be resolved?

Http.Api.Client layer is the short-hand api client for your module/application, not a layer for other clients to be injected or used.

Http.Api.Client use scenario:

1. You want to use the AbpAppX application service in your AbpAppY.
2. You add the AbpAppX.HttpApi.Client to your AbpAppY.Web (or Api.Host) layer and configure RemoteService at appsettings of AbpAppY (indicates that it will look for the sevice implementation in the remote service).
3. You can add AbpAppX.Application.Contracts to your AbpAppY.Application layer so that you are available to use the X application services in your AbpAppY application services.

These steps saves you from creating http clients from factories, serializing/deseralizing dtos and provides you hard-coded application service contract (IAbpAppXApplicationService) you can use without bothering to write wrappers for service end-points etc.

External service scenario:

Now you have an external http api service which is not Abp module/application but you want to use it in your Abp application naturally. Abp is layered application so your question is, which is the question of the era: Where do I put the code?

My answer to that is, it depends.

• If you will use the external service to combine with your application service dtos to show some view data, implement IHttpClientFactory in the Web layer. This will make your presentation layer dependent on external service.
• If you want to use the external service in your application logic and call external service in application services, then implement it in the Application layer. This will make your application and presentation layers dependent on external service.
• If you want to use the external service in your domain logic and call external services in the domain services, then implement in the Domain layer. This will make your domain, application, and presentation layers dependent on external service.

I wanted to point out the dependency graph. You need to decide the dependency level for your application to an external service.