locked
Service Bus for Windows Server - The API Version is not Supported RRS feed

  • Question

  • Hi, 

    We're working with Service Bus 1.1 for Window Server installed on our LAN. Our machines are Windows Server 2008. We're also using Service Bus Explorer (http://blogs.msdn.com/b/paolos/archive/2013/04/12/service-bus-explorer-2-0-released.aspx) to work with the instances.

    NB: This isn't production code, we're just trying to investigate the feasibility of hosting service bus internally on our 2008 Servers. 


    When using the Microsoft.ServiceBus.dll binary that is included with Service Bus Explorer (version is 2.0.30327) everything is working OK, I can create subscriptions and receive messages. 

    If I use any of the updates from NuGet since this version (current version, 2.1.3.0), an exception is thrown when trying to work with any of the instance items.

    "The remote server returned an error: (400) Bad Request. The api-version in the query string is not supported. Either remove it from the Uri or use one of '2012-03,2012-08,2013-04'.."

    Server stack trace: 
    Exception rethrown at [0]: 
       at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result)
       at Microsoft.ServiceBus.Common.AsyncResult`1.End(IAsyncResult asyncResult)
       at Microsoft.ServiceBus.Messaging.ServiceBusResourceOperations.EndGet[TEntityDescription](IAsyncResult asyncResult)
       at Microsoft.ServiceBus.NamespaceManager.OnEndTopicExists(IAsyncResult result)
       at Microsoft.ServiceBus.NamespaceManager.EndTopicExists(IAsyncResult result)
       at Microsoft.ServiceBus.NamespaceManager.TopicExists(String path)

    The same code works fine against service bus hosted in Azure, it's just when using the Windows Server installation that we see the problem. 

    Connection String for Window Server looks like this

    Endpoint=sb://dev-08.somehost.lan/DevSpace;StsEndpoint=https://dev-08.somehost.lan:9355/DevSpace;RuntimePort=9354;ManagementPort=9355;SharedAccessKeyName=owner;SharedAccessKey=DYkXL3uSRldOpb5CXUv4EdfdfeKprOnrHRzeZIVwfrdKk=

    I'm just creating Namespace and messaging Factory objects using the standard..

    this.namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
    this.messagingFactory = MessagingFactory.CreateFromConnectionString(connectionString);

    ...which both get created OK, it's just when trying to create Client instances that the Exception is thrown. 


    I'm not sure what the Exception is telling me. How is the api-version being transmitted & how can I go about resolving? 

    The only Hit I get when searching is this thread, but not sure if it applies in this case

    http://social.msdn.microsoft.com/Forums/windowsazure/en-US/55b88e96-301a-44e4-82e7-339b9f53881c/bad-request-apiversion

    Any advice appreciated, let me know if I can give any more information

    Thanks

    Dylan


    • Edited by Dylan Morley Friday, September 13, 2013 10:59 AM
    Friday, September 13, 2013 10:49 AM

Answers

  • Hi Dylan,

    the API version is hardcoded in Microsoft.ServiceBus.dll, which ships as part of the Service Bus or Azure SDK. Each version of this lib has a different string. SDK 2.0, for example, uses 2013-04, whereas 2.1 uses 2013-07 and 2.1.3.0 uses 2013-08.

    If you user REST/HTTP, you need to explicitly add apiversion to your request. If the apiversion is missing, Servcie Bus assumes SDK 1.5, which was the first SDK that contained the service Bus messaging features. The sample at http://code.msdn.microsoft.com/windowsazure/Service-Bus-HTTP-client-fe7da74a demonstrates the use of the apiversion string in the request URI.

    The reason for the apiversion is that Service Bus constantly adds new features. These features cause the client lib and protocol to change. For example, in SDK 2.1.3, Service Bus added the EnablePartitioning property to the QueueDescription. This property is not available in older versions of the SDK. If you request a queue description with SDK 2.1.3.0 or later (apiversion 2013-08 or greater), Service Bus will return a queue description that contains this property. If you request the same queue description with an older client (apiversion 2013-07 or smaller), Service Bus will not include this property into the queue description because the client would not be able to understand it.

    Azure Service Bus is compatible with all SDKs that have been released. This is not the case for Service Bus for Windows Server. Servcie Bus server is only aware of those SDKs that had been released at the time the server was built.

    Service Bus for Windows Server 1.0 works with all SDKs 1.8 or older (apiversion 2012-08 or smaller).

    Service Bus for Windows Server 1.1 works with all SDKs 2.1 or older (apiversion 2013-07 or smaller).

    Thanks, Ruppert

    • Marked as answer by Dylan Morley Friday, October 4, 2013 11:38 AM
    Thursday, October 3, 2013 7:14 PM

All replies

  • Hi Dylan,

    the API version is hardcoded in Microsoft.ServiceBus.dll, which ships as part of the Service Bus or Azure SDK. Each version of this lib has a different string. SDK 2.0, for example, uses 2013-04, whereas 2.1 uses 2013-07 and 2.1.3.0 uses 2013-08.

    If you user REST/HTTP, you need to explicitly add apiversion to your request. If the apiversion is missing, Servcie Bus assumes SDK 1.5, which was the first SDK that contained the service Bus messaging features. The sample at http://code.msdn.microsoft.com/windowsazure/Service-Bus-HTTP-client-fe7da74a demonstrates the use of the apiversion string in the request URI.

    The reason for the apiversion is that Service Bus constantly adds new features. These features cause the client lib and protocol to change. For example, in SDK 2.1.3, Service Bus added the EnablePartitioning property to the QueueDescription. This property is not available in older versions of the SDK. If you request a queue description with SDK 2.1.3.0 or later (apiversion 2013-08 or greater), Service Bus will return a queue description that contains this property. If you request the same queue description with an older client (apiversion 2013-07 or smaller), Service Bus will not include this property into the queue description because the client would not be able to understand it.

    Azure Service Bus is compatible with all SDKs that have been released. This is not the case for Service Bus for Windows Server. Servcie Bus server is only aware of those SDKs that had been released at the time the server was built.

    Service Bus for Windows Server 1.0 works with all SDKs 1.8 or older (apiversion 2012-08 or smaller).

    Service Bus for Windows Server 1.1 works with all SDKs 2.1 or older (apiversion 2013-07 or smaller).

    Thanks, Ruppert

    • Marked as answer by Dylan Morley Friday, October 4, 2013 11:38 AM
    Thursday, October 3, 2013 7:14 PM
  • Brilliant - thanks Ruppert, that explains everything. 

    Cheers, 

    Dylan

    Friday, October 4, 2013 11:40 AM
  • Hi Dylan or Ruppert.

    I've also downloaded and re-built the example Ruppert published, however, I can't see how to convince it to use my on-premise Windows Server Service Bus nor can I see how to use the 2.2 SDK NamespaceManager (for example) to use the Service Bus for Windows Server.

    I had hoped to develop a solution I can easily switch from on-premise to off-premise e.g. with a change to a connection string.

    Obviously there are subtle changes between the 'API's, but that's a restriction I'm prepared to accept.

    Here's what I'm doing.

    Works fine with NuGet package WindowsAzure.ServiceBus (version="2.2.7.0") but fails with NuGet package ServiceBus.v1_1 (version="1.0.2.0")

        public void TryUsingServiceBusForWindowsServerWithSdk2()
        {
          // For simplicity initialise the configuration parameters here to access the Service bus for Windows Server 
          string serverFqdn = System.Net.Dns.GetHostEntry(string.Empty).HostName;
          const int HttpPort = 9355;
          const int TcpPort = 9354;
          const string ServiceNamespace = "ServiceBusDefaultNamespace";
          const string QueueName = "ServiceBusQueueSample";
    
          // create a connection to the local service bus
          var connBuilder = new ServiceBusConnectionStringBuilder
          {
            ManagementPort = HttpPort,
            RuntimePort = TcpPort
          };
    
          connBuilder.Endpoints.Add(
            new UriBuilder
            {
              Scheme = "sb",
              Host = serverFqdn,
              Path = ServiceNamespace,
              Query = "api-version=2013-07" // doesn't appear to have any effect
            }.Uri);
    
          // The following doesn't work either
          ////connBuilder.Endpoints.Add(
          ////  new UriBuilder
          ////  {
          ////    Scheme = "http",
          ////    Host = serverFqdn,
          ////    Path = ServiceNamespace,
          ////    Query = "api-version=2012-03"
          ////  }.Uri);
    
          connBuilder.StsEndpoints.Add(
            new UriBuilder
            {
              Scheme = "https",
              Host = serverFqdn,
              Port = HttpPort,
              Path = ServiceNamespace,
              Query = "api-version=2012-03"
            }.Uri);
    
          string connectionString = connBuilder.ToString();
    
          var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
    
          // If we use NuGet package WindowsAzure.ServiceBus (version="2.2.7.0") then NamespaceManager.QueueExists throws the following exception:
          //   System.ArgumentException : The remote server returned an error: (400) Bad Request. The api-version in the query string is not supported. Either remove it from the Uri or use one of '2012-03,2012-08,2013-04,2013-07'...
          // It's ok if we use NuGet package ServiceBus.v1_1 (version="1.0.2.0")
          Assert.IsTrue(namespaceManager.QueueExists(QueueName));
        }
    

    MTIA

    Andy

    Monday, March 17, 2014 1:27 PM
  • Andy,

    I just realized you had another post to the forum here. Please see my comments below, which I responded to from your previous post on stackoverflow

    Stackoverflow post at...

    http://stackoverflow.com/questions/22456947/service-bus-for-windows-server-the-api-version-is-not-supported/22622117#22622117


    Blogging at Humanworkflow.net

    Tuesday, March 25, 2014 1:02 AM
  • Hello,

    I have exactly the same error when configuring workflow Manager for SharePoint 2013 SP1 using WPI. Can't succeed to resolve it using your comments. 

    Error : 

    Processing completed
    Installing auto-generated certificate.
    Granting 'Log on as Service' privilege to the RunAs account.
    Workflow Manager configuration starting.
    Configuring Workflow Manager runtime settings.
    The remote server returned an error: (400) Bad Request. The api-version in the query string is not supported. Either remove it from the Uri or use one of '2012-03'..TrackingId:4b035060-1d59-4fb1-b9ac-810bf6298576_GSP,TimeStamp:15/04/2014 09:34:20

    Any help would be appreciated, I am on this error since few days and can't resolve it even if I succed to register SPWorkflowService to my farm and display the worfkflowhost uri correctly.


    Alexandre DAVID

    Tuesday, April 15, 2014 9:42 AM
  • Hi Alexandre,

    Did you find a solution?


    Kind regards

    Saturday, July 5, 2014 1:33 PM
  • reinstalled everything

    Alexandre DAVID

    Monday, July 7, 2014 8:24 AM
  • I ended up at this question because I was getting the same error when connecting to Service Bus 1.1 using Service Bus Explorer 2.3.2.0. The issue was fixed by using Service Bus Explorer 2.1 which is also included in the Service Bus Explorer download. 
    Wednesday, August 20, 2014 9:55 AM