locked
EventHub management RRS feed

  • Question

  • With the WindowsAzure.ServiceBus library you are able to create an EventHub with simply a connection string, e.g.

    var builder = new ServiceBusConnectionStringBuilder(connectionString)
    {
         TransportType = TransportType.Amqp
    };
    
    EventHubClient.CreateFromConnectionString(builder.ToString(), path);
    Using the new Microsoft.Azure.Management.EventHub library, the EventHubManagementClient class appears to require an ActiveDirectory token. Is there a way to use the new libraries with just a connection string? We'd like to switch to the new event hub dedicated libraries, partly because they're .NET standard compatible, but not being able to perform management operations with just a connection string is a bit of a blocker. Thanks.

    Friday, May 19, 2017 9:12 PM

All replies

  • The Management library does use a different protocol path, interacting through the Azure Resource Manager (i.e. you don't don't talk to Event Hubs directly) and that has a uniform authorization model across all services, requiring AAD.
    • Proposed as answer by clemensv Tuesday, May 23, 2017 12:38 PM
    Tuesday, May 23, 2017 12:37 PM
  • "The Management library does use a different protocol path"

    The management library also appears to be significantly less robust. Are there any plans to add the management functions, which are in WindowsAzure.ServiceBus, to the Microsoft.Azure.EventHubs package? We want our libraries to be .NETStandard based, but the Microsoft.Azure.Management.EventHub package is a non-starter for us, and the WindowsAzure.ServiceBus package isn't .NETSTandard. Thanks.

    Tuesday, May 23, 2017 4:53 PM
  • The management library is using Azure Resource Manager, which is how all Azure resources are being provisioned and managed. We suggest that you leverage ARM Templates and use the ARM template deployment model instead of building on top of the API.

    ------------------------------------------------------------------------------------------------------------------

    Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members.


    • Proposed as answer by Nayana A S Wednesday, May 24, 2017 12:31 PM
    • Edited by Nayana A S Wednesday, May 24, 2017 1:07 PM
    • Unproposed as answer by jackhanbond Wednesday, May 24, 2017 5:13 PM
    Wednesday, May 24, 2017 12:31 PM
  • Hi clemensv,

    We have utility methods for creating hubs using the methods from both WindowsAzure.ServiceBus and Microsoft.Azure.Management.EventHub. We had been using the method from the SB library for months, and then decided to try and flip over to the EH based method. We quickly determined that the EH was significantly slower and less reliable, so we reverted back to the SB based method. You stated that "i.e. you don't talk to Event Hubs directly" which would explain the discrepancy. Are there plans to add the "direct" methods to the dedicated EH libraries?

    Wednesday, May 24, 2017 5:12 PM
  • The RM based methods are SIGNIFICANTLY less robust than the "direct" calls mentioned by clemensv. They are also more difficult to work with as they cannot accept just a connection string for management operations. So right now I'm stuck with:

    1) Continuing to use the Service Bus libraries (which are not .netstandard)

    or

    2) Look at the REST APIs and implement my own management library which is .netstandard

    Is the strategy going forward to eliminate the "direct" methods and force people to perform management operations via RM?

    Wednesday, May 24, 2017 5:21 PM
  • The strategy is to unify resource management across the whole Azure platform, correct.

    If you use ARM templates instead of API calls, the ARM template deployment runtime ought to deal with intermittent issues through that interface. 

    The runtime API for the Event Hubs .NET Core client and that of the new Java client now immediately reflects the API surface area available through AMQP. The same is true for the respective Service Bus clients.

    There are some limited management operations available on the runtime path where core usage scenarios specifically require dynamic behavior, such as "AddRule"/"RemoveRule" for Service Bus Subscriptions, and those are also available through AMQP. 

    The "native" HTTP management protocol surface area that backs the NamespaceManager of the NETFX API continues to exist, but we are, as you can see, encouraging customers to move to ARM and specifcially ARM templates: https://docs.microsoft.com/en-us/rest/api/eventhub/event-hubs-management-rest 

    Friday, May 26, 2017 12:56 PM