I've installed Service Bus for Windows Server on Server 2012. I'm trying to use the "Service Bus Explorer" management GUI to manage queues/topics.
I'm connecting to my service namespace by using the endpoint connection generated by the following PowerShell command:
Get-SBClientConfiguration -Namespaces 'MyNamespace' -Verbose;
Which generates:
Endpoint=sb://MyMachine/MyNamespace;StsEndpoint=https://MyMachine:9355/MyNamespace;RuntimePort=9354;ManagementPort=9355
And I am able to connect successfully.
PROBLEM:
In the Service Bus Explorer GUI, when I try to create a queue or topic, I get the following error in the Log output:
Exception: Object reference not set to an instance of an object.
Is there something I'm missing? I've gone through every Service Bus 1.0 setup guide I could find and everything seems to be in order with my installation.
I'm the author of the tool. In December I came across a similar problem:
If you GAC the Windows Azure Service Bus version of the Microsoft.ServiceBus.dll v.1.8:
The Service Bus Gateway and Service Bus Message Broker Windows services of Service Bus 1.0 for Windows Server start correctly, but they load the cloud dll instead of the on-premises one.
Any client application running on the same machine loads the cloud version of the dll.
If a client application connects to a local, on-premises SB namespace, The NamespaceManager and MessagingFactory get created correctly.
namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);
MessagingFactory = MessagingFactory.CreateFromConnectionString(connectionString);
The NamespaceManager object can bed used to create and delete entities (e.g. queues)
Instead, if the application tries to send or receive a message to/from a local queue with a MessageSender or MessageReceiver object created starting from the MessagingFactory, the operation fails and an exception (with 50002 error number) is catched by the application.
After removing the Windows Azure Service Bus Microsoft.ServiceBus.dll v.1.8 from the GAC and after restarting the Service Bus Gateway and Service Bus Message Broker Windows services, the problem disappears.
The client application is able to send and receive messages to/from a local queue linking both the cloud and on-premises dlls.
In a nutshell, if you GAC the cloud version of the dll, the Service Bus Gateway and Service Bus Message Broker Windows services start correctly, you can create messaging entities, but you get errors when an app tries to send/receive messages.
Questions:
Did you GACed the Windows Azure version of the dll?
What version of the Service Bus Explorer are you using (see the about form)?
Related
There is an example here that explains on how to send messages and receive messages using Azure Service Bus through a publisher and subscriber application.
My questions are about the subscriber application that receives messages:
Does registering in the application a message handler with subscriptionClient.RegisterMessageHandler(ProcessMessagesAsync, messageHandlerOptions); process the messages 24/7 until the application is shut down?
Can I deploy the subscriber console app in Azure only through Docker Container? If I don't want to use containers, what is the other hosting option I have? I have done CI/CD pipeline to host a WebAPI in Azure App Services from Visual Studio 2019 before.
Does registering in the application a message handler with subscriptionClient.RegisterMessageHandler(ProcessMessagesAsync, messageHandlerOptions); process the messages 24/7 until the application is shut down?
That's correct. That API is intended for the continuous flow of messages that needs to be processed.
Can I deploy the subscriber console app in Azure only through Docker Container? If I don't want to use containers, what is the other hosting option I have?
You can host continuously running Azure Service Bus processing using the following options:
Virtual Machine(s)
AKS/ACI
Service Fabric
Azure WebJobs (requires a WebApp)
An alternative option would be to look into Azure Functions. While it doesn't run 24/7, it allows a reactive type of application.
Am I getting something fundamentally wrong here...
I created a Service Fabric Mesh application in Visual Studio 2017, created 2 services and then tested on my local 5 Mesh Node cluster - worked as expected.
I then created a Service Fabric Cluster in Azure.
Next, I published my app to my Azure Subscription in the same Resource Group as my SF Cluster.
My app gets published fine and I can see the SF Mesh Application in my Azure Subscription, and I can access the services directly via the IP addresses that the Publish process tells me.
However, when I look at the SF Cluster Explorer for the Azure Cluster I created before publishing it doesn't show my Application or Services there?
I only see the services listed under the Mesh Application - but I can't see the public IPs listed anywhere for those services.
What am I missing? The services are clearly working as I can get data back out from them.
If I understand correctly, I believe you cannot see anything in SF Explorer because it's connected to regular Service Fabric and not your Mesh application which is not running on the Service Fabric cluster you provisioned. I haven't found any information on connecting to SF Explorer for Mesh yet. I expect MS will provide more information in the future. If you want to find the public IP for your Mesh application, try
az mesh gateway show -g ResourceGroupName -n GatewayName
I want to push Message in the queue using Azure Service Bus
I go through with lots of solutions but I found most of them are done by using Connection string of the Service Bus with SharedAccessKeyName and Value
but I want to achieve the same using sts uri
I tried with Get-SBClientConfiguration command also on power-shell to get stsuri
How we get stsuri for azure service bus authentication
I have a requirement where I need to put a ticket into an azure queue from a SSIS package.
I have previously set up control flows using "Message Queue Tasks" for add a ticket in MSMQ but did not know if there was way to trigger tickets into an azure service bus queue.
What I have tried:
As a alternative solution, I am accessing use a REST web service as a middle man. I trigger the webservice using "Web Service Task" which then puts a ticket in the azure queue.
There are two approaches of solving the problem in general
approach 01 : chicken out.
you could technically have a separate infrastructure piece between your SSIS package and the azure service bus queue which could reference the Azure SDK using nuget and put tickets for you, your SSIS package would then be calling this REST web api to put the ticket in.
approach 02 A : script task with .dll reference
You could reference the Microsoft.ServiceBus.dll inside a script task in the SSIS package which will construct a BrokeredMessage and put it in the queue.
The dll needs to be added to the GAC using gacutil.exe for the script task to work at runtime.
approach 02 B : script task calling azure service bus REST API
You could create a script task which calls and puts message using azure service bus REST API. There is a tutorial available here : https://msdn.microsoft.com/en-us/library/azure/hh416754.aspx but I never happened get beyond the point of sending actual data.
I'd like to know what is the best practice for doing incremental production deployment in azure with servicebus,
How to ensure that the messages don't get deleted when deploying a new version
Is there a backup mechanism to save the messages and load it back after the deployment is complete?
The Windows Azure Service Bus is a service which runs outside of your deployment, similar to Windows Azure SQL Database or Windows Azure Storage. This means that it does not depend on your deployment: you can deploy, remove, re-deploy your application without impacting the messages present in the Service Bus.
The only thing you'll need to take care of when you deploy a new version of your application is that the messages available in Service Bus Queues / Subscriptions might have been sent by the old version of the application. So take into account that the new version of your application will need to be compatible with these "old" message formats.