Service Bus Explorer

The Service Bus Explorer is a tool that you can use to manage and test the entities contained in an Azure Service Bus namespace.

C# (9.0 MB)
 
 
 
 
 
4.8 Star
(75)
88,497 times
Add to favorites
6/21/2017
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Connecting to Azure Pack Service Bus (Service Bus 1.1)
    3 Posts | Last post May 23, 2014
    • Hi Paolo,
      
      I'm trying to use the SBE 2.2.1.1 to connect to the Service Bus that I setup as part of the Windows Azure Pack setup on Service Bus 1.1. But every time I connect, I get an error saying "could not establish trust relationship for the SSL/TLS secure channel" during the "GetQueues" call. I think I'm not doing something right to setup the connection. Any guidance would be greatly appreciated. Let me know if you need to me to elaborate on anything I've said above.
      
      Thanks,
      Shahnaz.
    • Hi Paolo,
      
      Looks like you posted a new version of the tool yesterday. But if I'm reading the description correctly, SBE 2.3.2 is not compatible with Service Bus 1.1. It also says SBE 2.1.3 is compatible with Service Bus 1.1. How can I get my hands on SBE 2.1.3? Could you please share that version?
      
      Thanks in advance,
      Shahnaz.
    • Hi Shahnaz
      look inside the zip file, I included the .exe of the 2.1.3 version in it. Do you need the source code for 2.1.3? By the way, your issue is a security problem not related to the tool. I can tell you by experience. Try to solve the problem outside of the tool and when done use the connection string with the Service Bus Explorer. ;)
      Ciao
      Paolo
  • source code for 1.8
    2 Posts | Last post April 28, 2014
    • Hi Paolo,
      
      Would it be possible to get the source code for explorer 1.8? Currently in the download this is just an exe.
      
      Thanks
      Sean
    • Hi Sean
      for the code of the version 1.8 please contact me via email: paolos@microsoft.com.
      Ciao
      Paolo
  • Exe Only Download
    2 Posts | Last post April 28, 2014
    • Please consider offering 2 download links.
      1. With Source (same as you currently do)
      2. Exe Only.
      I know a few people, especially VB folks, that love your tool. They just want to point others to it. They trust you & don' want to examine the code. 
    • Thanks David for the heads up. Let me see what I can do at this regard!
      Ciao
      Paolo
  • When TransportType=Amqp sending fails with errors
    8 Posts | Last post March 13, 2014
    • Hi Paolo,
      
      I'm using Service Bus 1.1 (locally hosted instance) on a Win7 x64 machine.
      When I connect using the 2.1.0.2 version of the Service Bus Explorer and specify TransportType=Amqp (via the connection string as the Transport Type dropdown doesn't seem to work) then I get the following exception if I try to send messages to a queue:
      
      <11:53:26> Exception: An existing connection was forcibly closed by the remote host. Method <SendMessages>b__be: retry 1 of 10.
      
      It feels like a firewall/port issue, but all the inbound and outbound rules (created by the service bus installer) are active and enabled.
      
      Do you have any ideas what is wrong?
      
      (If I dont specify the TransportType then the sending works fine). 
    • Question: are you using Service Bus 1.0 or 1.1? SBE 2.1 works fine with 1.0 but not with 1.1. I assume that you use 1.1. Now, everything works fine on my machine:
       - I start SBE 2.1
       - I select a local namespace: Endpoint=sb://[MyNamespace].europe.corp.microsoft.com/ServiceBusDefaultNamespace;StsEndpoint=https://babosbird.europe.corp.microsoft.com:9355/ServiceBusDefaultNamespace;RuntimePort=9354;ManagementPort=9355;WindowsUsername=[LocalAccount];WindowsDomain=[MachineName];WindowsPassword=[Password]
       - I select Amqp as Transport Type in the Connect form.
       - Click Ok to connect
       - Send and receive messages to a queue.
      Now, if you continue to get the exception, try to individuate the call generating the exception and see what is the currently used TransportType. Contact me offline, but take into account that I'll be super busy till mid-April!
      Ciao
      Paolo
      
    • Hi Paolo,
      
      Thanks for the quick reply. I'm not sure how to get in contact with you offline so I'll post here and hope for the best :)
      
      Here are some more details:
      I am using ServiceBus 1.1
      I am using Service Bus Explorer 2.1.0.2 (from description.html: "The Service Bus Explorer 2.1. This version can be used with the Service Bus 1.1")
      
      I get a connection string from the Service Bus PowerShell command Get-SBClientConfiguration:
      Endpoint=sb://[MachineName]/ServiceBusDefaultNamespace;StsE
      ndpoint=https://[MachineName]:9355/ServiceBusDefaultNamespa
      ce;RuntimePort=9354;ManagementPort=9355
      
      In SBE I choose File->Connect and choose "Enter connection string..." and paste in the connection string from above.
      
      I then change the Transport Type: dropdown to Amqp and click OK
      
      If I then right click on my queue and choose "Send Messages" and click Start it works - HOWEVER - from what I can gather the connection is not actually using the AMQP protocol.
      
      To test this, I then choose File->Connect again (note that the Transport Type: dropdown is back to NetMessaging) I then modify the connection string again by adding ;TransportType=Amqp and then click OK (I don't bother with setting the Transport Type: dropdown again).
      
      Now when I right click my queue and choose "Send Messages" and click Start I get the error:
      
      <13:33:12> Exception: An existing connection was forcibly closed by the remote host. Method <SendMessages>b__be: retry 1 of 10.
      ...
      
      I have also written a small .NET test app and directly set the transport type to Amqp and tried to send a message to the same queue and I get the same error.
      
      Any thoughts?
      Cheers, Gaz
    • Ah ah ah... no worries, we can talk here ;) First of all thanks a lot for the long and detailed explanation! Tomorrow I will check on my machine and I'll follow up with you. By the way, it seems to me that your problem is not related to my tool, right? You said that you have also written a .NET app and you get the same exception... could you please send it to me? My email is paolos@microsoft.com. I'm quite busy in this period, so I'll do my best to look at it.
      Ciao
      Paolo
    • I contacted the Service Bus team, I'll follow up when I'll have an answer!
    • Hi Paolo,
      
      Thanks again.
      You are right, the problem is not related to your excellent tool, but the Service Bus in general not allowing Amqp messages to be sent.
      
      The example I used to test was based on this one here (I'll send you a copy):
      http://www.windowsazure.com/en-us/documentation/articles/service-bus-dotnet-advanced-message-queuing/
      
      As I mentioned, from what I can gather your tool is not using the value set in the Transport Type: dropdown.  However it is possible to set the TransportType it is entered directly in the connection string.
      
      That is a very minor issue compared to not being able to send messages at all when using Amqp :)
      
      Cheers,
      Gaz.
    • Quick update: I fixed the ConnectForm to use the TransportType from the dropdownlist. More, now you can also manually edit the TransportType in the ConnectionString textbox, and the value in the dropdownlist will change accordingly between NetMessaging and Amqp. Now, when using Amqp you have to change the value of the RuntimePort from 9354 to 5671. I tried and it worked like a charm. The new version of the tool automatically changes the value of the RuntimePort in the connection string depending on your TransportType selection. I'm quite busy doing other stuff, as soon as possible I'll publish the new version. Stay tuned!
    • Fantastic Paolo.
      
      I tested your solution (update the TransportType and RuntimePort) and it works for me too :)
      
      I had asked the same question on stackoverflow and got the same answer today:
      http://stackoverflow.com/questions/22291729/what-is-blocking-amqp-transporttype-when-using-service-bus-for-windows-server-s/22337116?iemail=1&noredirect=1#22337116
      
      Do you know if the required change to the RuntimePort when using Amqp is in the documentation? (I can't seem to find it).
      
      Thanks again for your great support :)
  • Failure to connect to service bus on premise
    3 Posts | Last post March 12, 2014
    • Hi Paulo,
      
      As requested moving this question - http://social.msdn.microsoft.com/Forums/windowsazure/en-US/e0491f9b-7826-478e-9c2d-ed444c435530/failure-to-connect-to-service-bus-using-service-bus-explorer-from-a-client?forum=servbus - here.
          
    • I added the windows credentials to the connection string as suggested and also updated the code in ServiceBusHelper.cs - public bool Connect(ServiceBusNamespace serviceBusNamespace) - at Line 759
      
      tokenProvider = TokenProvider.CreateOAuthTokenProvider(new Uri[] { new Uri(serviceBusNamespace.StsEndpoint) },new NetworkCredential(serviceBusNamespace.WindowsUserName, serviceBusNamespace.WindowsPassword, serviceBusNamespace.WindowsDomain));
      namespaceManager.Settings.TokenProvider = tokenProvider;
      
      This now connects successfully to the service bus, and I created a simple topic and subscription.
      When I try to send a message to the topic I got the same error message - "The token provider was unable to provide a security token...."
      
      I updated Line 764 of ServiceBusHelper
      From
          MessagingFactory = MessagingFactory.CreateFromConnectionString(connectionString);
      To
          MessagingFactory = GetMessagingFactory();
      
      I'm now getting this error message returning straight away - ie I don't believe its time out related.
      
      <11:10:02> MessagingFactory successfully created
      <11:10:07> Exception: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.8126322'.. Method <SendMessages>b__be: retry 1 of 10.
      .
      . retry 10 times
      .
      <11:10:17> Sender[0]:
      
                  - Exception occurred: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:01:00'.
      
                  - Message Count=[0] Messages Sent/Sec=[0] Total Elapsed Time (ms)=[0]
      
                  - Average Send Time (ms)=[0] Minimum Send Time (ms)=[0] Maximum Send Time (ms)=[0] 
      
      
      Any advice on what to try to fix?
      
      Thanks,
      Paul
    • Hi Paul
      you have my email address, please send me the modified code, I'll take a look to it. Question: can you try to create a repro with a console app to see if you get the same error? That would be also much easier to debug. Thanks!
      Ciao
      Paolo
  • Service Bus Explorer Version 1.8 - SourceCode
    2 Posts | Last post February 28, 2014
    • Hi
      I'm thinking about using Service Bus - since my machines will be SharePoint with the Workflow Manager - I have to use Service Bus 1.0. Is the Service Bus Explorer Source Code still available? ( I binged for it - but without luck)
      txs flori
    • Hi Flori
      Try this link: http://1drv.ms/1mLLh6a
      Ciao
      Paolo
  • repair and resubmit
    8 Posts | Last post February 17, 2014
    • Hi Paolo,
      
      We are using Service Bus Explorer 2.1.0.2 and finding it is a very useful tool. I am using the NetMessagingBinding for publishers and subscribers. I noticed that when a message got deadlettered because of exceeeding retries, when I repaired and resubmitted (using the WCF body type setting), the message was never being consumed.  
      
      So to force the consumer to pick up resubmitted dead letters I added:
      [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
      public class MyConsumer :  IMyContract
      
      Why is that?  Does the deadlettering process change the message meta data?
      
      Thanks
      
      
      
      
      
    • Hi seanTaR with *the message was never being consumed* do you mean the original message that ended up in the deadletter or the clone that you resubmitted?
      Ciao
      Paolo
    • Hi Paolo,
      
      When I repaired and resubmitted the dead lettered message and it moved into the transactional queue, my WCF consumer does not pick up the message. (I can see this as I have extensive logging.)
      However, despite it not being "consumed" the message does again get deadlettered after 3 retries. So something is incrementing the retry count.
      
      I would also add that my consumer does consume messages that have not been previously dead lettered.
      
      thanks 
      
      sean
      
      
    • Hi Sean
      this sounds like your consumer fails to receive the message and retries until the message gets deadlettered again! Question: what message format do you select when you resubmit the message? Make sure you select WCF from the Body Type combobox otherwise the message won't be sent in a SOAP envelope and the WCF consumer won't be able to receive it! Hence, if it retries to receive message, the latter will run out the max delivery count and end up in the deadletter queue!
      Ciao
      Paolo
    • Hi Paolo,
      
      I definitely selected body type: WCF.  Which didn't get consumed.  But when I added the attribute to my consumer, the same message got consumed.
      
      Thanks
    • I am not sure if this was relevant, or maybe an issue with the explorer but my message has this structure, with a wrapper around it.
      
      public class MyMessage<TDto> where TDto: class
          {
              public TDto Dto { get; set; }
          }
      
      This then allowed us to just write one publisher for all types of message.
    • Thanks for the feedback guys! It would be great if you could document in a blog post the solution mentioned by MrKevorkian and add the link to this thread! :)
    • Hi,
      
      No that does not fix the issue.  You still need add this attribute: 
      
      [ServiceBehavior(AddressFilterMode = AddressFilterMode.Any)]
      public class MyConsumer :  IMyContract
      
      on your consumers to be able to receive repaired and resubmitted dead letters.
  • Can't compile the tool
    5 Posts | Last post December 12, 2013
    • Hi Paolo,
      
      I can't compile to tool. When trying to do so I get the following compilation error:
      No overload for method 'SendNotificationAsync' takes 2 arguments	C:\Code\Azure\Service Bus Explorer\C#\Controls\HandleNotificationHubControl.cs	line: 1610	column:49
      
      I saw that the project has a reference to C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\v2.2\ref\Microsoft.ServiceBus.dll. I decompiled it and I indeed see that there is only 1 method SendNotificationAsync while in the online documentation there are 3 overloads of the method, 2 of them taking 2 arguments. See: http://msdn.microsoft.com/en-us/library/microsoft.servicebus.notifications.notificationhubclient.sendnotificationasync.aspx.
      
      I installed Windows Azure SDK through Visual Studio 2012 as explained here: http://msdn.microsoft.com/en-us/library/windowsazure/ff687127.aspx#Install It launched the Web platform installer and installed Windows Azure SDK for .NET (VS 2012) - 2.2 (which seems to be the latest version).
      
      The Azure SDK MSDN documentation I pointed to does not show any information regarding versioning so I am not sure to what version the documentation apply to, but I would guess it's the latest one. http://msdn.microsoft.com/en-us/library/microsoft.servicebus.notifications.notificationhubclient.sendnotificationasync.aspx
      
      So it seems I have a version issue isn't it?
      Do you have any advise?
      
      Thanks,
      
      Francois
    • Slight update.
      I saw that in the bin\Debug folder you had a copy of Microsoft.ServiceBus.dll. I decompiled it and there I indeed saw the 3 overloads and if I reference it instead of the SDK's library, the project compiles.
      
      So may I ask where did you get this version of the library from? Are you using Visual Studio 2013 (the SDK seems to be different between VS 2012 and 2013 - but that might just be the Visual Studio tool part, not the actual SDK libraries)?
      
      For addition precision, Microsoft.ServiceBus.dll in your source code has a File Version = 2.2.31022.0 while the one I have in C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\v2.2\ref has a lower file version of 2.2.30924.1
      
      Cheers,
      
      Francois
      
    • Hi Francois
      you can just right click the Project and select Manage NuGet packages to see and update the libraries installed via NugGet. You can retrieve the last version of the Microsoft.ServiceBus.dll this way or manually from http://www.nuget.org/packages/WindowsAzure.ServiceBus/
      Ciao
      Paolo
    • Hi Paolo,
      
      Installing the NuGet package for the WindowsAzure.ServiceBus did indeed load the correct library version and stored it in the package folder under my project. Thanks for the solution!
      
      So my guess here is that the Windows Azure SDK is is also using the Azure Service Bus library but of an older version.
      
      Ciao :)
      Francois
    • True. From time to time, the product group releases a version that is newer than the one contained in the current Windows Azure SDK. :)
      Ciao
      Paolo
  • App.Config is not valid
    2 Posts | Last post December 02, 2013
    • Hi Paolo,
      There is an extra   <system.net> at line #36, which is causing build to fail. Just an FYI :). 
    • Thanks for the heads up mate, fixed.
      Ciao
      Paolo
  • Microsoft.ServiceBus.ConnectionString value doesnt show up in the connect screen
    2 Posts | Last post December 02, 2013
    • If add my namespace details to Microsoft.ServiceBus.ConnectionString in app.config, it doesnt showup in connect dialog anymore
    • Because it was not supported... so far. :) Now it is. :)
      Ciao
      Paolo
41 - 50 of 65 Items