Closed rachanee-mwp closed 3 years ago
Thanks @rachanee-mwp for the feature request. It is appreciated if you want to contribute, otherwise we will be working on it based on the next versions.
@hikalkan - any update on Azure Service Bus support / ETA? Thanks!
hi @MedAnd There is no news for now. Still in the backlog.
Any PR would be appreciated :)
If no work is started already on this feature, me and my friend would take it and try implement. I would write here, if there will be some question. You can observe progress on this fork https://github.com/CrazyBaran/abp
To create topics in azure service bus it need to be additional layer for azure managment. Cause topics need to be first initialized as it is in Kafka. SubscriptionId and other authorization should be in AzureServiceBus configuration or we will go with some global authorization for azure? How it works for azure blob storage?
@CrazyBaran Have you noticed that abp now (v3.3) supports Rebus for the distributed event bus, and that there is also a Rebus project to enable Azure Service Bus transport for rebus??? https://github.com/rebus-org/Rebus.AzureServiceBus
I'm wondering if the these two implementations would be an effective way to achieve the goal. Have not looked in to the details of either implementation yet but hope to do so in the next week or so.
This seems to work. Steps 1-5 you do in each module/service that either sends or receives messages:
1) Add the Volo.AbpEventBus.Rebus package (I added to Domain project)
2) Add DependsOn for AbpEventBusRebusModule to Domain project module
3) Add the Rebus.AzureServiceBus package (I'm using v8.1.5 with ABP 4.2.2) to the Domain project module
4) Override PreConfigureServices in Domain project module
public override void PreConfigureServices(ServiceConfigurationContext context)
{
base.PreConfigureServices(context);
var configuration = context.Services.GetConfiguration();
PreConfigure<AbpRebusEventBusOptions>(options =>
{
options.InputQueueName = configuration["ServiceBus:SubscriberName"];
options.Configurer = c =>
{
c.Transport(t => t.UseAzureServiceBus(configuration["ServiceBus:ConnectionString"], configuration["ServiceBus:SubscriberName"]));
};
});
}
5) Create the proper configuration settings for the above code in settings file and/or your app service configuration in Azure. Each service should have a unique subscriber name, but can share the same connection string to your Azure Service Bus.
6) Create some IDistributedEventHandler methods to receive and handle events
7) Publish some distributed events (few ways to do this, see the docs)
8) Deploy and run your code, and cause messages to broadcast
End Result:
Just trying to figure out how to fix all my broken integration tests which are failing because of service bus initialization.
We have had a requirement for a client project that we working to implement the Distributed Event Bus as Azure Service Bus and decided to write two modules that we contribute back to the community.
We followed the same patterns that were implemented for RabbitMQ and Kafka where there is a separate module for Volo.Abp.AzureServiceBus that implements common configuration, services, and factories that can be reused in any module.
The second module Volo.Abp.EventBus.Azure implements the configuration and Azure Service Bus as the Distributed Event Bus.
We will submit a PR for the two modules and their unit tests in the next couple of days
@gdeswardt Excellent.
After some further review, I have concerns with depending on Rebus and look forward to reviewing your work.
Any PR would be appreciated :)
@hikalkan here you go :-)
I have submitted a PR for this specific feature. Looking forward to reviews and feedback.
We would like to use Azure Service Bus for services communication. Right now we are using ABP Commercial and see that you have distributed event bus for RabbitMQ, so we would like to have that implementation for Azure Service Bus as well.